Improve forecast trial docs #224
Conversation
Revise the forecast trial section to add more specific, "real-world" details such as it being an electric utility wanting to do the trial and the focus being on forecasting power generation from the utility's fleet of solar PV power plants. Also add additional examples that build off of the first example. This way readers can focus on the differences in the examples, rather than having to re-read a copy&paste version of Example 1 and try to figure out what the differences are.
…cast schedule and quality flags
|
I'm generally okay with the changes, but will make a couple minor revisions before submitting (e.g., say "persistence forecast" instead of "persistence" in case some readers are not familiar with persistence forecast methods). |
|
I'm thumbs down on editing the Use Cases as if they are supposed to be user instructions. The Use Cases were meant to guide development, not to provide a step-by-step how-to. I think they should be left static. If we want a User Guide, let's make that and put it here: https://forecastarbiter.epri.com/documentation/ |
|
That's a good point and agree that we should have a User's Guide, that actually goes through code examples. I know David already developed some example code for the previous trials - basically i think we can just use those. |
Improve the forecast trial documentation by adding new examples and revised discussions. The goal is not to provide a step-by-step guide, but rather to inform users about the core concepts involved in running a forecast trial using the Arbiter. The examples and discussion in this PR reflect both (1) lessons learned from past forecast trials (using the Arbiter) and (2) feedback from industry stakeholders (forecast users and forecast providers).
This PR is meant to resolve issue #223